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Abstract 

The security posture of a computer can be adversely af- 
fected by poorly-designed devices on its USB bus. Many 
modern embedded devices permit firmware to be up- 
graded in the field and the use of low-cost microcon- 
trollers in these devices can make it difficult to perform 
the mathematical operations needed to verify a crypto- 
graphic signature. The security of many of these upgrade 
mechanisms is very much in question. For a concrete ex- 
ample, we describe how to tamper with a firmware up- 
grade to the Apple Aluminum Keyboard. We describe 
how an attacker can subvert an off-the-shelf keyboard by 
embedding into the firmware malicious code which al- 
lows a rootkit to survive a clean re-installation of the host 
operating system. 



1 Introduction 

In 2005, the Defense Science Board of the Department of 
Defense expressed concerns about the migration of mi- 
croelectronics foundries from the United States to for- 
eign countries and its impact on the security of mi- 
crochips and microelectronic components delivered to 
the government and military and used in critical infras- 
tructure [3]. If an adversary is able to gain access to a 
microelectronic component during the design phase, then 
a clandestine modification will corrupt every unit manu- 
factured and the confidentiality, integrity or availability 
of any system using such a component can be compro- 
mised. Moreover, given the complexity of modern sys- 
tems, such a modification can be deeply embedded into 
a system and difficult to detect and attribute. 

In [16], King et al. implemented a general-purpose 
malicious processor by modifying a VHDL implemen- 
tation of the Leon3 open source SPARC processor. In or- 
der for unprivileged software to access privileged mem- 
ory locations, the MMU was modified so that when a 
particular magic sequence was observed on the data bus, 



all protection checking was disabled. By reserving lines 
in the instruction cache and data cache and using proces- 
sor debugging hardware, a shadow mode mechanism was 
created to allow malicious code to be bootstrapped via a 
UDP packet. These malicious modifications were imple- 
mented using only a 0. 13% increase in logic gates and al- 
lowed the implementation of malicious services such as 
root privilege escalation, a login backdoor and the theft 
of passwords from individuals using the system. 

Vertical disaggregation in the semiconductor industry 
has continued since the 1990's and fabless IC production 
is now common. The significantly lower costs of capital 
and lower costs of operation offshore and the infeasibility 
of having low-volume manufacturing within the United 
States only increases the possibility of this kind of threat 
being realized. 

Tlircals from malicious hardware are not limited to mi- 
croelectronic components and recently, consumers have 
suffered security compromises simply through the pur- 
chase and use of off-the-shelf consumer electronics. In 
2006, Apple shipped a number of iPod music/video 
players pre-installed with a Windows virus called Rav- 
MonE.exe [4] and TomTom shipped a number of its GO 
910 GPS navigation devices [6] infected with Windows 
malware. In a promotion in Japan in 2006, McDon- 
ald's distributed 10,000 MP3 players pre-installed with 
a password-stealing trojan [5], 

In 2007, Seagate shipped a number of its Maxtor 
Personal Storage 3200 hard drives with a trojan called 
Virus.Win32.AutoRun.ah which was capable of dis- 
abling anti-virus software and was designed to steal lo- 
gin credentials to World of Warcraft and a number of 
online Chinese games [7]. During the 2007 holiday sea- 
son, BestBuy sold a number of digital picture frames pre- 
installed with a Windows virus under its house brand In- 
signia [8]. In 2008, Hewlett-Packard shipped a number 
of infected USB keys with its ProLiant servers [9] and 
Asus shipped infected Eee Box mini-computers [10]. 

Although it is believed in all of these cases that com- 



puters used in manufacturing or testing were inadver- 
tently infected and that malware was able to "hitch" a 
ride, these episodes illustrate the feasibility of an attacker 
subverting the supply chain. 

Recently, counterfeit Cisco networking equipment 
originating from China has been discovered in the United 
States. The counterfeit equipment was often found due to 
duplicate MAC addresses, duplicate serial numbers and 
having a higher failure rate than genuine equipment. In 
2008, a PowerPoint presentation of an Office of Man- 
agement and Budget briefing given by the FBI regard- 
ing the problem of counterfeit Cisco equipment was in- 
advertently leaked onto the internet [18]. The presen- 
tation described a number of rings located in the United 
States that were actively selling counterfeit Cisco gear on 
the auction site eBay and to Cisco Gold/Silver partners 
through whom equipment ultimately ended up at numer- 
ous government agencies and defense contractors. The 
presentation asks rhetorically if the motive behind the 
counterfeit gear is for profit, or if it is state-sponsored 
with the intention to "cause immediate or premature sys- 
tem failure during usage," "gain access to otherwise se- 
cure systems," or "weaken cryptographic systems." 

Due to intense pressures to reduce time-to-market, a 
number of consumer hardware products can have their 
firmware field-upgraded, and often firmware upgrades 
are released to fix bugs and problems that are discovered 
after the product has shipped. In fact, there is an offi- 
cial USB device class specification for doing firmware 
upgrades over USB [2] although we are not certain how 
widespread its use is. The problem is that an attacker 
may also decide to upgrade the firmware on a device with 
their own code for malicious purposes by taking advan- 
tage of weaknesses in the upgrade mechanism. 

In some cases, the owner or operator of the embed- 
ded system makes deliberate efforts to tamper with the 
system without the sanction of the manufacturer. For ex- 
ample, there is an entire industry which sells aftermarket 
performance products for various brands of automobiles 
that increase performance by changing the air-fuel mix- 
ture, removing the top speed governor, increasing rev- 
limit, etc. often at the expense of fuel economy and in- 
creased emissions. These software modifications are ap- 
plied to a vehicle through its OBD II connector or by 
removing the ECU from the vehicle and sending it in for 
bench-programming. Other examples include firmware 
for the Linksys WRT54G, jailbreaking/unlocking soft- 
ware for the Apple iPhone and third-party firmware for 
lower-end digital cameras which unlock RAW shoot- 
ing and other advanced features typically found only 
on higher-end models. Television pirates have repro- 
grammed the firmware of cable and satellite receivers 
and attacked smartcards for the purpose of signal theft. 



2 Prior Work 

Researchers have recently become interested in attacking 
insecure software update and installation mechanisms. 
Package managers for Linux and BSD operating systems 
are typically run as superuser in order to modify system 
software. They differ in whether cryptographic signa- 
tures are on the root metadata, are embedded within the 
packages themselves or on detached package metadata. 
In [15], Cappos et al. investigated popular package man- 
agers such as Yum, Apt, YaST, ports, etc. and discovered 
weaknesses in every one they looked at. If an adversary 
has control of a mirror or is performing a man-in-the- 
middle attack via poisoning ARP or DNS or spoofing 
DHCP, a variety of attacks can be performed. Clients can 
be continuously served outdated repository metadata in 
order to prevent security updates or served outdated, but 
legitimately signed packages with known vulnerabilities 
("metadata replay"). Yum can be subverted by rewrit- 
ng package metadata to cause additional packages to be 
nstalled or by returning a repomd . xml file of unlim- 
ted size to fill up the disk of a client and cause denial of 
service. 

An attacker can of course setup their own mirror for 
popular Linux distributions such as Ubuntu, Debian, Fe- 
dora, CentOS and openSUSE and perform these kinds 
of attacks. Over the years, numerous sites serving 
open-source software have been compromised with the 
2003 compromise of the GNU project's ftp server be- 
ing among the most serious [1]. Just recently in August 
2008, an unknown attacker compromised a number of 
servers at Red Hat, including a machine used to sign Fe- 
dora packages. Red Hat claimed however that the pack- 
age signing key itself was not compromised, but did issue 
a new signing key [11]. 

For Windows and Mac OS X operating systems, 
in [12] Amato developed an open-source toolkit called 
EvilGrade for the exploitation of popular software prod- 
ucts which perform insecure updates. An attacker per- 
forming a man-in-the-middle attack can then exploit a 
vulnerable application by injecting a fake update. Appli- 
cations which fail to verify updates and have modules in 
the toolkit include iTunes, Winamp, WinZip and the Sun 
Java plugin. The toolkit even includes a module for per- 
forming malicious updates to machines running the Mac 
OS X operating system. 

However, the idea of tampering with software updates 
is by no means new. In the past, before the widespread 
penetration of the internet, patches were delivered on 
magnetic or cartridge tape and shipped through the mail 
or sent by courier. K. Mitnick has said that long ago 
he successfully stole the source code to a DECNET/E 
protocol sniffer from a small company called Polar Sys- 
tems using a fake update. Mitnick took a legitimate up- 



date tape for the VMS operating system from Digital 
Equipment Corporation, added code to install a backdoor 
into the login program, repackaged the box and shrink- 
wrapped it with a counterfeit shipping label. He then 
obtained a UPS uniform, delivered the fake update tape 
to the firm in person and waited for the update to be in- 
stalled [17]. 

In high-security environments such as government in- 
stallations and defense contractors, we have often heard 
stories of the USB ports of computers being disabled by 
filling them in with epoxy glue. On some computers 
with poorly-designed USB devices, we do not believe 
that this is sufficient to protect against rogue USB de- 
vices. For example, we performed most of the work in 
this paper on a 4th-generation Apple Macbook Pro lap- 
top computer (with model identifier MacbookPro4, 1) 
and even without plugging any devices into its external 
USB ports, the computer already has four devices on its 
USB bus: the bluetooth device, the internal iSight web- 
cam located above the LCD screen, the integrated key- 
board/trackpad and the infrared receiver. 

In this paper, we discuss a practical attack that can be 
performed today which blends the threats of malicious 
hardware and malicious software updates. 

3 Keyboards 

As the primary point of data entry in a computer, key- 
boards and typewriters before them have long been of in- 
terest to attackers. In the 1980's, numerous news sources 
reported that typewriters in the U.S. Embassy in Moscow 
were discovered to have devices planted inside of them 
which sent out signals encoding keystroke information 
using the power cord at television frequencies. Appar- 
ently, other countries with embassies in Moscow discov- 
ered similar devices in the 1970's. 

In 1999, the FBI obtained warrants to enter the office 
of Nicodemo S. Scarfo and Frank Paolercio in New Jer- 
sey and encountered an encrypted file. In order to de- 
crypt this file, the FBI later returned to the office and 
covertly installed a keystroke logger on Scarfo's com- 
puter in order to capture his PGP encryption passphrase. 
The FBI obtained the passphrase and is alleged to have 
obtained evidence of illegal gambling and loanshark- 
ing. In 2001, the DEA conducted an investigation of 
an MDMA manufacturing operation. They received au- 
thorization to enter the Escondido, CA office of Mark 
Forrester and Dennis Alba to install a keylogger onto 
their computer in order to obtain passphrases for PGP 
and their accounts on the encrypted mail service Hush- 
mail. com. 

Free and commercial software keystroke loggers are 
widely available. logKext is a free and open source 
keystroke-logging kernel extension for Mac OS X. Given 



the ease of using SetWindowsHookEx ( ) in the Mi- 
crosoft Win32 API, there are literally thousands of 
keystroke loggers for Microsoft Windows. 

Hardware keystroke loggers for both PS/2 and USB 
keyboards are also widely available commercially and 
typically are devices that sit inline between the terminat- 
ing plug of the keyboard and the port on the host com- 
puter. Parasite devices that sit inside the keyboard are 
also commercially available, but require more effort to 
install. Keystroke-logging mini-PCI cards that can be in- 
stalled into laptops are also commercially available. In 
general, it is difficult to extract the captured data and 
so in [19], Blaze et al. built a hardware logger that per- 
turbed the inter-keystroke delay and used the delays as a 
covert channel and for interactive protocols such as SSH 
and VNC, they were successful in extracting keystroke 
data without having to physically access the logger. Re- 
searchers have even reported success at the recovery of 
keystrokes from recordings of acoustic emanations from 
somebody typing at a keyboard [ ]. 

4 The Apple Aluminum Keyboard 

In August 2007, Apple introduced new wired and wire- 
less keyboards to accompany its redesigned iMac desk- 
top computer products. The keyboards have low-profile 
keys and come in a thin, aluminum enclosure. The wired 
keyboard terminates in a USB A male connector and con- 
nects to a desktop computer through an available USB 
port. The wireless keyboard uses Bluetooth 2.0. The 
wired keyboard which has a model number of A 1243 and 
an Apple part number of MB 1 10LL/A. It is a compound 
USB device in that the device is actually a hub with a 
keyboard plugged into it and an available USB port on 
each side of the keyboard. The keyboard we examined 
has avendoridof 0x05ac and aproduct id of 0x0220, 
and its integrated hub has a product id of 0x1 6. This 
keyboard is widely deployed and until March 2009, came 
standard with all new iMac and Mac Pro desktop com- 
puters from Apple, although a customer had the option to 
pay additional money to get the wireless keyboard in lieu 
of the wired keyboard. The keyboard can also be pur- 
chased separately from a desktop computer for $49.00 
USD directly from Apple and from other retailers. 

In March 2009, Apple introduced another wired key- 
board with model number A 1242 and an Apple pail num- 
ber of MB869LL/A. The layout of the keys on this key- 
board is identical to the Bluetooth keyboard and does not 
have a numeric keypad. This keyboard has a vendor id of 
x 5 a c and a product id of x 2 1 d, and its integrated 
hub has a product id of 0x1 5. Both of the wired key- 
boards can be used without difficulty on almost any mod- 
ern machine via the USB human interface device class. 

In this paper, we examine the wired keyboard with the 



numeric keypad introduced in 2007. We were unable to 
find sales figures for the three models of keyboards cur- 
rently available for sale by Apple, but we believe that it is 
the most widely deployed keyboard out of the three due 
to its cost and length of time on the market. 

By examining a disassembled keyboard, we learned 
that internally there is a Cypress CY7C63923 microcon- 
troller in a 48-pin SSOP package surface mounted to the 
circuit board of the keyboard. The CY7C63923 is an 
8-bit microcontroller with a Harvard architecture, 256 
bytes of RAM and 8 kilobytes of flash. The chip belongs 
to Cypress Semiconductor's enCoRe II family of chips 
designed primarily for ease of use in low-speed USB de- 
vices. The chip can support one low-speed USB device 
address with three endpoints: the required control end- 
point and two additional endpoints. Upon plugging the 
keyboard into a computer, we learned that two IN inter- 
rupt endpoints are configured with addresses of 0x81 
and 0x82. They both have a blnterval value of 10. 
Endpoint 0x81 has a wMaxPacketSize of 8 and end- 
point 0x82 has a wMaxPacketSize of 1. 

On the circuit board adjacent to the microcontroller, 
there is a Microchip 25LC040A serial EEPROM in an 
8-pin SOIC package. It is a 4-kilobit EEPROM with an 
SPI interface. Although adjacent to the microcontroller, 
by following circuit traces on the board we determined 
that the EEPROM is actually connected to the Cypress 
CY7C65630 USB 2.0 hub controller in a 56-pin QFN 
package on the board. A high-level schematic of the key- 
board is in Figure 1 . We traced the circuit paths for the 
LED on the keyboard underneath the Caps Lock key. 
The anode is connected to Vdd and the cathode is con- 
nected through resister R7 to pin 8 of the microcontroller, 
which is P2.7. This means that the LED is active-low on 
this pin. 

upstream USB 



CY7C65630 hub 



CY7C63923 



- USB port 

- USB port 



keyboard matrix 
Figure 1 : A high-level schematic of the keyboard. 

5 Apple's Firmware Update 

Version 1.0 of the Aluminum Keyboard Update from Ap- 
ple was released on April 8, 2008 and is available on- 



line [13]. Apple released the update to address com- 
plaints from users about keys repeating unexpectedly 
while typing and other issues. The resulting down- 
load file is named AlKybdFirmwareUpdate . dmg. 
From the disk image file, a flat package file named 
AlKybdFirmwareUpdate .pkg can be obtained. 
When running this installer package, an applica- 
tion called "Aluminum Keyboard Firmware Update" 
is created in the /Applications/Utilities di- 
rectory. In Mac OS X, applications are actually 
stored in a directory structure with ".app" appended 
to the name of the application. In the directory 
Contents/Resources within the application's di- 
rectory, two files called HIDFirmwareUpdaterTool 
and kbd_0x0069_0x0220 . irrxfw are of interest. 



5.1 Reversing the Firmware Update 

The magic number for the application Aluminum 
Keyboard Firmware Update is OxCAFEBABE 
which indicates that it is a fat/universal binary. For con- 
venience, we primarily examined the Intel x86 portion 
of the binary in this Cocoa application. Examining the 
CustomerKB.nib file from the English localization, 
the NSButton push button in the lower right-hand cor- 
ner of the user interface had a target outlet set to the 
MyMainController class and its action was set to 
doUpdate :. 

The applicationDidFinishLaunching: del- 
egate method starting at address 0x00004fe7 runs 
after the application has launched and been initial- 
ized, but prior to the first event. The method 
calls a number of routines. It calls a routine 
which consults the file SystemVersion .plist in 
/System/Library/CoreServices/ to determine 
whether the running operating system version is at least 
10.5.2. It finds the keyboard to update by calling the rou- 
tine starting at0x000035e0 which uses the I/O Kit li- 
brary to search for devices on the USB bus with a ven- 
dor ID of 0x0220 and product IDs of 0x222, 0x2 21, 
0x22 0, and 0x22 8, in that order. However, we exam- 
ined a number of Apple Aluminum keyboards "in the 
wild" and only observed keyboards having a product id 
of 0x220. 

The application checks a number of properties of the 
keyboard and checks the validity of the firmware im- 
age file kbd_0x0069_0x0220. irrxfw in the bun- 
dle. The firmware validity checking routine is called 
CRC32: and is the 75 byte routine starting at 
0x00003005. Despite the name, this routine does not 
do CRC32 at all and in fact, it simply just adds up the 
bytes of the firmware image file and the application ver- 
ifies that the sum is 0x252ed7. 

An otool disassembly of the first 64 bytes of 



Filename Size 

AlKybdFirmwareUpdate . dmg 1,568,432 

AlKybdFirmwareUpdate . pkg 1,483,229 

HIDFirmwareUpdaterTool 76,480 

kbd_0x0069_0x0220.irrxfw 18,253 



SHA-1 

8c914be94e31alf2 54 3bd5 90d72 3 9aebclebb0c0 
7ele7 5a4d937f6ba4 4f97a7bfc72e3a04fc9albe 
3d5 64d6cb3bd731218 7 6a2f9a0b9b8 5ca032a3fb 
Cf2b7ac6d4575b8f57ba55 62abld94ff33773 6f4 

)f interest from Apple, Inc. 



00004. 

00004. 
00004' 
00004' 
00004' 
00004- 
00004. 
00004. 
00004- 
00004. 
00004. 
00004. 
00004. 
00004. 
00004. 
00004- 
00004. 
00004. 
00004. 
00004. 



pushl 



addl 
popl 



$0x24, %esp 
0x08 (%ebp) , %ebx 
0x000080f0,%eax 
%ebx, (%esp) 
%eax, 0x04 (%esp) 
0x000090e0 



al, 
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e2f 



0x00004. 
$0x0 0000015, 0x10 (%ebp) 
0x00008040, %eax 
%ebx, 0x08 (%ebp) 
%eax, 0x0c(%ebp) 
$0x24, %esp 
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oooo. 



oooo. 
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■4cb3 
>4cb6 



jbel 



0x08 (%ebp) ,%eax 
$0x69, 0x50 (%eax) 
0x00004cb3 
0x00008040, %eax 
0x08 (%ebp) ,%edx 
$0x00000011,0x08 (%e 
%eax, 0x04 (%esp) 
%edx, (%esp) 
0x000090e0 
0x00008044, %eax 
%eax, 0x04 (%esp) 
0x08 (%ebp) ,%eax 
%eax, (%esp) 
0x000090e0 
0x08 (%ebp) ,%edx 
$0x69, 0x50 (%edx) 
0x00004d56 



Figure 4: Part of the version checking code 



Figure 3: First 64 bytes of doUpda 



doUpdate: is shown in Figure 3. When the 
user presses the update push button, the instruction at 
0x00004e0a causes a 239 byte routine located from 
0x00003850 to 0x0000393e to be called 1 which 
checks whether the machine doing the update is plugged 
into a wall outlet. 2 Requiring that the machine doing the 
update be plugged into a wall outlet is understandable 
since losing power during a firmware upgrade can result 
in a damaged keyboard, but the reader may disable this 
check by changing the jne at 0x00004ell to jmp, 
i.e. changing the 0x7 5 to OxEB. 

If the reader's keyboard has already had the firmware 
update applied to it, the update program will display 
a dialog box saying that the firmware is already up- 
to-date and refuse to apply the update. A disassem- 
bly of some of the code which performs the check is 
shown in Figure 4. The version checking can be by- 
passed by making the first conditional short jump uncon- 
ditional, i.e. changing 0x75at0x00004c81to OxEB, 
making the second conditional near jump unconditional, 
i.e. changing OxOf 8696000000 at 0x00004cba 
to 0xe99700000090, and then removing the condi- 
tional jump at 0x00004820, i.e. changing 0x740e to 



5.2 Obfuscation 

If the application is satisfied that a keyboard that 
needs to be updated is attached and the user 
presses the update button, then it invokes the 

HIDFirmwareUpdaterTool with the arguments 
-parse kbd_0x00 69_0x0220 . irrxfw to first 
check that the firmware image can be parsed and then 
invokes it with the arguments -progress -pid 
0x220 kbd_0x0069_0x0220. irrxfw. The 

second invocation does the heavy lifting of actually 
updating the firmware of the keyboard. The firmware 
image file kbd_0x0069_0x0220 . irrxfw is "en- 
crypted" and the core of the decryption routine is 
displayed in Figure 5. Let A denote the following 83 
byte sequence: 

31 lc ef 62 df a7 43 23 78 92 22 6a 
38 12 14 a4 65 02 2b 00 9c 00 57 5e 
10 85 50 73 dO bl 17 2b 49 ac 49 c4 
33 21 b4 48 23 8c 27 98 12 34 80 00 
48 ff b4 8f 04 2e 24 2d 92 c7 82 e2 
a6 a5 20 20 98 11 84 26 b7 cc 28 f3 
e6 98 38 23 dc ba 28 44 42 39 44 



00004086 movzbl %al,%edx 

00004089 incl %ecx 

0000408a movzbl 0x00006020 (%edx) , %eax 

00004091 notl %eax 

00004093 xorb (%esi),%al 

00004095 xorb %al, Oxf f f f f f 55 (%ebp, %edx; 

0000409c cmpb %cl,%bl 

0000409e movl %ecx,%eax 

000040a0 ja 0x00004086 

Figure 5: Decryption code 



£> 52 denote the following 53 byte 



and let B = B B 1 ■ 
sequence: 

12 14 a4 65 02 2b 00 9c 00 57 5e 10 

85 50 73 dO bl 17 2b 49 ac 49 c4 33 

21 b4 48 23 8c 27 98 12 34 80 00 48 

ff b4 8f 04 2e 24 2d 92 c7 82 e2 a6 
a5 20 20 98 11 

The decryption routine reads the firmware file in 83 byte 
chunks with the ith chunk XOR-ed with the l's comple- 
ment of A and then each byte XOR-ed with B i+ i e mo( j 53 
to produce the "plaintext." So the first 83 bytes of 
kbd_0x0 6 9_0x02 2 O.irrxf ware XOR-ed with the 
complement of A and then each byte is XOR-ed with 
0x17. The next 83 bytes are XOR-ed with the comple- 
ment of A and then each byte is XOR-ed with 0x2b, 
and so forth. The sum of each byte in the plaintext is 
then computed and verified to be 0xl057f8. 

5.3 Bypassing the obfuscation 

We did not make an attempt to completely understand 
the algorithm used to obfuscate the firmware image, as it 
turns out that the tool HIDFirmwareUpdaterTool 
sends "cleartext" over the USB bus to the keyboard's 
bootloader. The unobfuscated firmware file can be easily 
obtained from memory. 

$ gdb -q HIDFirmwareUpdaterTool 
(gdb) b *0x4abc 
Breakpoint 1 at 0x4abc 
(gdb) r -progress -pid 0x220 

kbd_0x0069_0x0220 . irrxfw 
Breakpoint 1, 0x00004abc in ?? () 
(gdb) dump binary memory dump. bin 
0x61ec 0x89ec 

The block size in the microcontroller's flash mem- 
ory appears to be 64 bytes and by examining the file 
dump . bin 35 bytes at a time, the pattern becomes read- 
ily apparent. The first 8820 bytes of dump. bin are 
what is relevant. The firmware image is sent over the 



USB bus 32 bytes at a time and for every grouping of 
35 bytes in dump .bin, the first 3 bytes indicate where 
the following 32 bytes are written into flash. The first 
2 bytes encode the block number and the third byte en- 
codes whether the 32 bytes are in the top half or the bot- 
tom half of the block. 

5.4 I/O Kit API 

In Mac OS X, the I/O Kit API is a collection of frame- 
works for device driver development and communica- 
tion with hardware. HIDFirmwareUpdaterTool ac- 
cesses the keyboard over the USB bus using services 
from I/O Kit. The tool creates a device-matching dic- 
tionary to find the Apple Aluminum keyboard in the I/O 
Registry, which is a memory-resident, tree data struc- 
ture 3 that maintains the configuration of devices in the 
system. When hardware is added or removed from the 
system, the I/O Registry is automatically updated to re- 
flect the change in hardware configuration. The I/O Reg- 
istry on a Mac OS X system can be examined using the 
developer tool "I/O Registry Explorer" or ioreg from 
the command line. 

In order to first communicate with the I/O Kit, 
it is necessary to obtain the I/O Kit master port, a 
Mach port. HIDFirmwareUpdaterTool uses the 
IOMasterPort () function and passes the result- 
ing port to functions that require a port argument, 
but in recent versions of Mac OS X, the constant 
klOMasterPortDefault defined in IOKitLib.h 
can instead be passed. At the end, the port is released 
using mach_port_deallocate. 

Then, IOServiceMatching ( ) with an argument 
of "IOUSBDevice" is used to create a device-matching 
dictionary. This is a broad search of the I/O Registry 
for all USB devices. The search is narrowed by tak- 
ing the resulting dictionary and adding rules requiring 
that the vendor ID match 0x0 5ac and the product ID 
match 0x02 2 and passing the resulting dictionary to 
IOServiceGetMatchingService () to obtain the 
registered IOService object. This function is called in 
lieu of the API call which returns an iterator over the set 
of matching devices. The program expects at most one 
matching device and simply accepts the first matching 
device on the USB bus. In the unlikely event that a com- 
puter has multiple Apple Aluminum keyboards attached 
to it, then only one of the attached keyboards will have 
its firmware updated. 

Then IORegistryEntryCreateCFProperty ( ) 
is used to query the bcdDevice property of the key- 
board, which is a binary-coded decimal representation 
of the current firmware version of the keyboard. The 
keyboards we have observed have a bcdDevice value 
of 0x6 7 prior to the firmware update and a value of 



0x69 afterwards. HIDFirmwareUpdaterTool 
will refuse to update a keyboard if it detects that its 
version is above 0x68. This version checking can be 
disabled by removing the near jump if above instruction 
at 0x00003373, i.e. changing OxOf 873b0a0000 to 
0x909090909090. 



5.5 Bootloader operation 

The keyboard does not have an interrupt OUT endpoint, 
and so the control endpoint has to be used to enter 
the bootloader mode. After running the routine at 
0x000020c3, the bootloader of the microcontroller 
is running and the keyboard is no longer running. 
By examining the IOUSBDevRequest passed to 
IOUSBDeviceClass : : deviceDeviceRequest ( ) 
in this routine, and after consulting the USB standard, 
we determined that an HID-specific request is being used 
to put the keyboard into bootloader mode. In particular, 
the bmRequestType was 0x21 and the bRequest 
was 0x0 9 indicating that a Set_Report request is sent to 
the keyboard. The wValue was 0x0 3 0a which means 
that the request is a feature report with a report ID of 
0x0 a. The wlndex was 0x0 000 which means that the 
request was being sent to interface zero and the pData 
was simply 0x0 a. The bootloader specifies in its device 
descriptor that it has a bDeviceClass of OxFF and has 
a product ID of 0x022 8. In order to see the firmware 
upgrade data go to the keyboard, we looked at the data 
being written over the USB bus in x 2 d 6 9 . 

The 260 byte routine starting at 0x00002d69 
handles the bulk of the writing and reading to the 
keyboard over the USB bus. Each call results in a 
packet of data being sent to the keyboard followed 
by a read to get the response. The indirect call at 
0x00002dcf calls interf aceWritePipe ( ) 
in IOUSBInterfaceClass which sends 
over the contents of the 64 byte buffer start- 
ing at 0x0 0a7c0, and the indirect call at 
0x00002e07 calls interf aceReadPipe ( ) in 
IOUSBInterfaceClass which reads the response 
into the 64 byte buffer starting at 0x0000a760. The 
code which prepares the first 64 byte buffer transmitted 
to the keyboard is shown in 6. The first 64 byte packet 
sent to the keyboard is 

ff 38 00 01 02 03 04 05 06 07 00 00 

00 00 00 00 00 00 00 00 00 00 00 00 

00 00 00 00 00 00 00 00 00 00 00 00 

00 00 00 00 00 00 00 00 00 53 00 00 

00 00 00 00 00 00 00 00 00 00 00 00 

00 00 00 00 

and by the asl.log at 0x00005094, we ascertain that 
this call has the effect of instructing the bootloader to 



00004c66 


movl 


0x000060a0,%es 




00004c6c 


cmpb 


$0x00, 0x0000607d 


00004c73 


movb 


SOxff, (%esi) 


00004c76 


movb 


$0x38, 0x01 (%es 




00004c7a 


movb 


$0x00, 0x02 (%es 




00004c7e 


movb 


$0x01, 0x03 (%es 




00004c82 


movb 


$0x02, 0x04 (%es 




00004c86 


movb 


$0x03, 0x05 (%es 




00004c8a 


movb 


$0x04, 0x06(%es 




00004c8e 


movb 


$0x05, 0x07 (%es 




00004c92 


movb 


$0x06, 0x08 (%es 




00004c96 


movb 


$0x07, 0x09(%esi) 


00004c9a 


je 


0x00004ccl 


00004c9c 


xorl 


%edx,%edx 


00004c9e 


movl 


%esi,%eax 


00004ca0 


leal 


0x2d(%esi) , %ecx 


00004ca3 


addb 


(%eax) ,%dl 


00004ca5 


incl 


%eax 


00004ca6 


cmpl 


%ecx,%eax 


00004ca8 


jne 


0x00004ca3 


00004caa 


movb 


%dl,0x2d(%esi) 


00004cad 


movl 


0x000060a0,%edx 


00004cb3 


movl 


%esi,%eax 


00004cb5 


addl 


$0x12, %edx 


00004cb8 


movb 


$0x00, 0x2e (%eax) 


00004cbc 


incl 


%eax 


00004cbd 


cmpl 


%eax, %edx 


00004cbf 


jne 


0x00004cb8 





Figure 6: USB packet setup routine 



Return value Reason for error 

0x00 Device did not respond error 

0x08 Flash protection error 

0x10 Communication checksum error 

0x80 Invalid command error 

Figure 7: Error codes 



go into bootloader mode. Observe the simple checksum 
calculation done from 0x00004c9e to 0x00004caa. 
For the example above, Oxff + 0x38 + 0x01 + 0x02 
+ • • • + 0x07 = 0x153 which is 0x53 mod 0x100. 

The first two bytes of the USB packet is used to 
issue commands to the bootloader. We have already 
seen that ff 3 8 corresponds to entering the bootload 
mode, and by the asl.log calls in 0x00004ce0 and 
0x00004dd9 respectively, we determined that f f 3a 
commands the bootloader to verify flash memory and 
ff 3b exits the bootloader. The command ff 3 9 
means to write to flash memory. The return values from 
0x00002d69canbe interpreted by examining the code 
from 0x00004b63 to 0x00004b8b. See Figure 7. 

There is also a final checksum at the very end, which 
is computed as a sum of all the firmware blocks mod 
0x10000. In this case, the data from blocks 0x0 2 to 
0x4b are summed and the checksum is 0x4e41b which 
is 0xe41b mod 0x10000. This is stored in the last 
flash write packet in big endian format. 

6 Exploitation 

6.1 A benign exploit 

For ethical reasons, the firmware modification we de- 
scribe is benign. The firmware is modified so that the 
LED under the Caps Lock key of the keyboard will 
flash momentarily when the keyboard is first plugged 
into a system. However, malicious payloads can be de- 
veloped by individuals with mal-intent. 

Since the LED is active-low on pin P2.7 which cor- 
responds to register 0x02 on the microcontroller, we 
searched the unobfuscated firmware image for instruc- 
tions of the form MOV reg[0x02], expr which 
start with the opcodes 0x62 0x02. We found the se- 
quence 0x62 0x02 0x80 in block 0x0c which did 
in fact turn out to be the instruction MOV r e g [ x 2 ] , 
0x80. The final checksum for the entire firmware image 
was 0x4e41b. By replacing 0x80 by 0x00, the new 
checksum is 0x4e39b and so 0xe41b in the last block 
has to be replaced by 0xe3 9b. 

As a proof-of-concept, the following edited gdb ses- 
sion performs the changes mentioned above and demon- 
strates code execution on an Apple Aluminum keyboard. 



$ gdb -q HIDFirmwareUpdaterTool 

(gdb) tb *0x226a 
Breakpoint 1 at 0x226a 

(gdb) r -progress -pid 0x220 

kbd_0x0069_0x0220.irrxfw 
HIDFirmwareUpdaterTool version 1.6.0 
#1##2##3# 
Breakpoint 1, 0x0000226a in ?? () 

(gdb) set {char}0x64b9 = 0x00 

(gdb) set { short } 0x845e = 0x9be3 

(gdb) c 

6.2 Rootkit persistence 

Any malicious code embedded into the firmware would 
be immune to the typical rootkit detection methods 
which examine the integrity of the filesystem, check for 
hooks or direct kernel object manipulation, or detect 
hardware and/or timing discrepancies due to virtualiza- 
tion in the case of a virtual-machine based rootkit. Such 
code could also completely bypass the remote attestation 
of a Trusted Platform Module, if one were present in the 
computer. As far as everybody is concerned, our code is 
simply the user typing commands at the keyboard. 

When the operating system enumerates the keyboard, 
a rootkit can use a custom control endpoint signal to in- 
dicate to malicious firmware on the keyboard that the at- 
tacker's rootkit is still operational on the host and that 
no action is necessary. However, if the keyboard does 
not receive such a signal, it can send malicious com- 
mands to the host computer to re-establish control to the 
attacker. It would obviously be ideal for this to occur af- 
ter a certain period of inactivity by the legitimate user in 
the hopes that he/she is not using the computer to witness 
any unauthorized activity. 

As an example, the keyboard could send the fol- 
lowing keystrokes: Command-Space, followed by 
terminal and RETURN, then followed by exec 
/bin/sh 0</dev/tcp/12 7. 0.0. 1/4444 
1>&0 2>&0 and RETURN, where 127.0.0.1 is 
of course replaced by the IP address of the attacker's 
machine. In Mac OS X, Command-Space activates 
Spotlight and terminal is typed into the Spotlight 
search box to launch the terminal application. Then 
exec is used to send a shell back to the attacker [14]. 
The above command just sends a shell back to port 4444 
on localhost. The firewall in the Mac OS X Leopard 
operating system is by default not enabled, and in any 
case, does not block outgoing connections. In the event 
that the user uses an outbound firewall like Little Snitch, 
an extra RETURN at the end of the above sequence of 
keystrokes will select the default option of allowing 
the outbound TCP connection from Terminal. app. This 
would allow a rootkit to persist even if the user has 



performed a clean re-installation of Mac OS X on their 
computer. 

6.3 Denial of service 

It is very easy to brick a keyboard by interrupting the 
bootloader during firmware re-programming. However, 
a keyboard bricked in this way can generally be un- 
bricked by reflashing to 0x6 9 firmware. If the boot- 
loader still runs, then HIDFirmwareUpdaterTool 
can be invoked with the arguments -progress -pid 
0x228 kbd_0x0069_0x0220.irrxfw. We did not 
investigate whether the bootloader itself could be over- 



7 Conclusion 

Reverse-engineering Apple's keyboard firmware update 
was a fairly simple exercise. Apple could have attempted 
to obfuscate the binary as they do in the well-known seg- 
ments with the 0x8 flags set on the LC -SEGMENT load 
commands in certain Apple binaries (indicating AES en- 
cryption) such as Finder.app, Dock.app, etc. which are 
designed to hinder the piracy of the Mac OS X operating 
system. Apple could have issued a PT_DENY_ATTACH 
ptraceO request as they do in iTunes as an anti- 
debugging measure. However, such methods can be by- 
passed without much difficulty. 

For a device as simple in design as a keyboard, it is 
hard to imagine why a firmware update mechanism is 
even required. Many other devices have firmware update 
mechanisms that we believe can also be exploited by at- 
tackers for malicious purposes. 
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Notes 

1 This cannot be seen from the assenthk listing due to message pass- 
ing in Objective C. 

2 Curiously, Apple's developer documentation sa\s that 
IOPMCopyBatterylnfo () is unsupported on all Intel CPU 
ba ed j terns and yet, Apple uses it in this routine anyway. 

3 Well, it is almost a tree. A RAID disk controller is an example of 
an exception. 



2SNID=349sLanguage=l, 2007. 



archive.org/web/200802110 95252/ 



